Chapter 3-13: Table Processes |
The Table Widget at Runtime When the Input process executes, after the Pre-Display event point runs, the Table Widget(s) will be loaded. Each Table Widget will execute the Event Points in the Table Source process as described above. You can prevent a Table Widget from loading by setting --- WIDGET RELOAD DATASOURCE to "N" in the Pre-Display event point. You might want to do this if the PCF for the Table Source contains a large number of records, and you don't want the table loaded until the user has a chance to enter some filter criteria. If you have specified an Option for either the Single click or Double Click actions, then those Options will fire when the user clicks a row. This is no different than the user clicking a button that fires an Option, so the Option Intercept event point will execute first. If --- OPTION still contains the USER XX value after the Option Intercept event point ends, then Appx will continue it's normal processing, i.e., it will attempt to run the specified Optional Child, then re-execute the normal event points for the image, including Pre-Display. This means your Table Widget will be re-executed as well, and the data reloaded (unless you have turned off the --- WIDGET RELOAD DATASOURCE spec). If you do not want this to happen, you should set --- OPTION to blank in the Option Intercept Event Point. Conversely, if you want the Table Widget to reload, but do not want all the other Event Points in the Input process to fire, you can use the --- .WIDGET RELOAD DATASRC subroutine, then set --- OPTION to blank. Since --- OPTION is blank, no other event points will execute, and since --- WIDGET RELOAD DATASRC was run, the Table Widget will re-execute. Note that if you do not set an Option to fire when the user selects a row or rows, you will need some other method for the user to signal that they are done selecting rows. For example, you could put another button on the image that they click. You can test for that Option, and if true, examine the --- SLCTKEYS memory file to see which keys were selected. The --- SLCTKEYS memory file contains one record for every row the user selected (including any rows you pre-selected via --- SELECT RECORD). This file is keyed on the Parent Type of the Table Widget (which will always be WIDGET), the row and column position of the Table Widget and a unique sequence number for each row selected. The --- SLCTKEYS PCF KEY VAL field contains the Primary key to the PCF record. You do not have to include the primary key of the PCF file in the Table Widget, Appx will supply that value regardless. If you have more than one Table Widget on the image, you can use the row and column position to differentiate them. Or, if you gave your Table Widget a name, you can use that to read the --- WIDGET file, then use --- WIDGET KEY in a BEG AT/END AT loop on --- SLCTKEYS to only read records for that Table Widget. For Example:
The --- SLCTKEYS PCF KEY VAL field is an alpha field that may contain binary characters if the PCF Primary key is a numeric field. In this case, you cannot simply move the --- SLCTKEYS PCF KEY VAL field to the numeric field, you need to have a group field that contains the numeric field and move --- SLCTKEYS PCF KEY VAL to that field.
The user can click a column heading to sort the data in ascending or descending order, and they can drag the columns to re-arrange them. These changes will remain until the process is restarted, at which point the widget will revert to the designer's specifications. You can also create or modify the Table Widget via ILF code. The fields unique to the Table Widget are:
WIDGET WIDGET TYPE - must be TABLE |
Application Design Manual "Powered by Appx Software"1332 ©2006 By APPX Software, Inc. All Rights Reserved |
